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ABSTRACT 



In July 1985, the Chief of Xaval Operations (CNO) in response to increasing mes- 
sage traffic on the Fleet Broadcast System mandated the creation of the Administrative 
Message designation and the capability to remove or intercept such messages from the 
Fleet Broadcast should queue conditions warrant. In June 1986, the Commander, Xaval 
Telecommunications Command (CXTC), promulgated guidance concerning the acti- 
vation of an administrative message intercept. The CXTC guidance on activation of an 
intercept was based on output queue level of the congested Fleet Broadcast channel. 
Based on results generated from a GPSS V simulation of a single Fleet Broadcast output 
channel and the message responses of the affected Naval Communications Area Master 
Stations (XAVCAMS) to the CXTC guidance, a more comprehensive framework, con- 
sisting of two phases, policy and guidance development and on-station decision making, 
is proposed for use in decision making on the activation of an administrative intercept. 
The implementation of the recommended strategy would ensure a decision making 
process that is sensitive to both the priorities of the policy makers and the variables 
present in the communication environment. 
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I. INTRODUCTION 



A. BACKGROUND 

In July 1985, the Chief of Naval Operations (CNO) promulgated a procedure to all 
naval commands which required the originators of all narrative messages to determine 
if a message is administrative or operational in nature. The annotation of the message 
type on the message would permit the Fleet Commander-in-Chief (FLTCINC), through 
the Naval Communication Area Master Station (N'AVCAMS), to remove administrative 
messages from the Fleet Broadcast channels should message traffic loading warrant. 

In June 1986, Commander, Naval Telecommunications Command (CNTC), issued 
management guidelines for the administrative message intercept capability. CNTC also 
requested comments and/or recommendations from the NAVCAMS concerning the 
guidelines. The responses from the NAVCAMS was generally negative and dealt with 
key issues. One key issue was the failure of the CNTC guidance to consider the oper- 
ating environments and the special needs required when operating in these environ- 
ments. Another issue dealt with infringement on the NAVCAMS' control of traffic 
management; the issuance of a set policy/guideline on the implementation of adminis- 
trative intercepts restricts the NAVCAMS from fully utilizing all local expertise and re- 
sources available. Finally, the effectiveness and efficiency of the administrative intercept 
was questioned; specifically, questions were raised on the value of the intercept in its 
present form. 

B. OBJECTIVES AND RESEARCH QUESTIONS 

This thesis has multiple objectives; the first objective is to present the concept of the 
administrative message intercept and to examine the capabilities of the intercept. Ad- 
ditionally, the responses from the NAVCAMS will be examined to consider the validity 
of their claims. This study will also, through the use of a computer simulation system, 
investigate the effects of different traffic characteristics on the effectiveness of the inter- 
cept. From this simulation it is hoped to present a more complete set of considerations 
for activating an intercept. 

C. SCOPE 

The research conducted in this thesis focuses upon the Fleet Broadcast sections of 
the Naval Communications Processing and Routing System (NAVCOMPARS). Using 
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the General Purpose Simulation System V, a simple model of a single output channel 
of the Fleet Broadcast is simulated. Due to the lack of historical data and/or actual 
NAVCOMPARS operation time, the model did not receive full validation via compar- 
ison. However, it is felt that the model does portray similar behavior, in terms of output, 
to provide beneficial data for analysis. It is further felt that this model and its results 
can serve as a foundation for future study in this particular area of Naval Communi- 
cations. 

D. ORGANIZATION OF STUDY 

The first chapter of this research provides a brief introduction into the issues con- 
cerning the implementation of an administrative message intercept. This chapter also 
points out the objectives and research questions emphasized. The second chapter ex- 
amines both the concept and mechanics of the administrative message intercept. The 
third chapter presents a review of factors to be considered when forming a decision on 
activating an intercept; the chapter also provides a summary of CNTC's guidance and 
the responses submitted by the individual NAVCAMS. Chapter IV details the General 
Purpose Simulation System V and presents the model of the Fleet Broadcast output 
channel used. Chapter V is a presentation and discussion of simulation results. Chapter 
VI is a proposed decision making process for both the policy maker and the 
operator/manager. The final chapter concludes with recommendations and suggested 
future topics of research. 
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II. NAVCOMPARS - ADMINISTRATIVE TRAFFIC INTERCEPT MODE 



A. INTRODUCTION 

Within the Naval Communications Processing and Routing System 
(NAVCOMPARS),! intercept of administrative message traffic is only one of many 
traffic control methods available to the system operator. In this chapter the following 
topics will be discussed: 

1. Fleet Multichannel Broadcast System 

2. Administrative Traffic Intercept 

3. Administrative Traffic Intercept Modes 

4. Message Reentry Modes 

B. FLEET MULTICHANNEL BROADCAST SYSTEM 

The Fleet Multichannel Broadcast System (MULCAST) serves as the United States 
Navy's primary method of sending general service (genser) message traffic between 
forces afloat and the Naval Telecommunications System (NTS). The Multichannel 
Broadcast is a non-termination2 system capable of being received by properly equipped 
and frequency aligned units. 

The Multichannel Broadcast is primarily operated through two transmission sys- 
tems: 

1. Fleet Satellite Broadcast (FSB) System 

2. High Frequency Broadcast (HFB) System 

1. Fleet Satellite Broadcast (FSB) System 

The Fleet Satellite Broadcast serves as the primary method of transmitting the 
Multichannel Broadcast. The FSB's normal configuration requires a one channel as- 
signment for uplink and downlink from one of the U.S. Navy's satellite communication 
systems (i.e. Fleet Satellite Communications System (FLTSATCOM), Gapfiller System, 
Leased Satellite System (LEASAT)). Using multiplexing technology, sixteen individual 

1 For a detailed s umm ary of NAVCOMPARS see Appendix A. 

2 A termination is a special full-time dedicated circuit between a fleet unit and the NTS. 
Terminations are usually required because of high traffic flow due to major exercises/operations, 
special operations, or command requirements. 
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channels comprising the Multichannel Broadcast are combined into a single 1200 Baud 
FSB channel for uplink to the system satellite. The sixteen channels include: 

• 11-75 Baud general service teletype (TTY) channels 

• 2-75 Baud special intelligence channels 

• 2-75 Baud meteorological channels 

• 1 - frame synchronization channel 

The fleet units, receiving the satellite downlink, demultiplex the single 1200 Baud signal 
back into the original sixteen individual 75 Baud TTY channels. User communication 
requirements and equipment availability then determine which of the sixteen channels 
are actually decrypted and utilized. It should be noted that equipment availability is 
usually the most significant factor in determining channel utilization. The amount of 
equipment on hand to decrypt and utilize a channel is dependent on the class of ship and 
it's mission. 

Of the eleven genser TTY channels available at a Communication Station eight 
comprise the Fleet Broadcast. Normal configuration is six channels controlled directly 
from the Fleet Center while the remaining two channels are controlled in other spaces. 
Three of the six channels are run continuously as common or type channels while the 
remaining three are run as either overload, rerun, or contingency channels. [Ref. 1: pp. 
68-69; Ref. 2: pp.39-40[ 

Common channels generally contain messages for all fleet units in the Commu- 
nication Area (COMMAREA); type channels carry messages which are designated for 
ships of a particular warfare type (i.e. amphibious, destroyer). 

Overload channels are used as a means of expanding system output capacity. 
When an overload is activated, traffic which was designated for a primary channel is 
then split between that primary channel and the overload. This, in effect, doubles the 
output capacity of the transmitting station. The activation of the overload also requires 
that the receiving fleet units allocate additional decryption and processing equipment to 
the overload. 

Rerun channels are used for ensuring that units receive all traffic designated for 
them. In principle, a rerun channel rebroadcasts message traffic which was originally 
broadcast on a primary channel some time period before. For example, a rerun channel 
will transmit message traffic one hour after the initial message broadcast over a common 
or type channel. This enables the receiving units to recopy any message which it may 
have missed on the initial broadcast. 
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2. High Frequency Broadcast (HFB) System 

High Frequency multichannel communication serves as the secondary trans- 
mission medium for the Fleet Broadcast. Because of the system's versatility and 
survivability, and the growing vulnerability of satellite communications systems, HF 
communications have received increased emphasis to meet present and future needs. 
The Chief of Naval Operations (CNO) has mandated that, at a minimum, a complete 
16 channel HF broadcast capability be maintained in each of the major communications 
areas [Ref. 3: p. VIII-1]. 

Multichannel HF communications are similar in concept to the satellite com- 
munications mentioned above except that the transmission medium is HF vice satellite 
(SHF, UHF). Additionally, the capability exists to simultaneously key on other fre- 
quency bands any message being transmitted on HF. This process of "simo-keying" 
further improves the probability of success on these non-satellite communication sys- 
tems. The effects of using HF as a transmission medium will be expanded upon in later 
chapters. See Figure 1 on page 6. 

C. ADMINISTRATIVE TRAFFIC INTERCEPT 

Message interception is used as a means of demand management; selected messages 
are removed from the system thereby lessening the total number of messages actively 
being processed. The purpose of an administrative traffic intercept is to 

. . . allow the Broadcast Keying Station (BKS) to remove from and/or suspend 
queueing to the broadcast (during extreme traffic loading periods) ZYB marked 
messages [Ref. 4: p. 1 ]. 

Administrative traffic are messages which have been deemed by the message origi- 
nator to be non-operational in nature. The originator identifies this traffic by inserting 
ADMIN in the Message Handling Instruction (MHI) block of the message form. 

Within NAVCOMPARS, after input via an Optical Character Reader (OCR) or 
some other system input device, the message is marked with the Operating Signal 
(OPSIG) ZYB by the resident software. The operating signal ZYB then serves to iden- 
tify a message as administrative to the NAVCOMPARS. Once converted to ZYB, the 
administrative message is flagged for possible interception should traffic conditions 
warrant. 

Additional processing will assign a message, whether operational or administrative, 
a Routing Indicator (RI) based on the addressee (fmal destination). The RI assigned 
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will then be matched with a Logical Reference Number (LRN) which designates the 
output path required for message delivery. 

At this point in processing, a specific message is cither in queue awaiting trans- 
mission. or enroute to a LRN's queue. As mentioned above, it is possible for broadcast 
queues to become congested due to high traffic loading: in this situation the broadcast 
LRN becomes a likely candidate for some sort of demand management action (i.c. an 
intercept). 

If the system manager invokes an administrative intercept all messages flagged with 
ZYB OPSIGs will be intercepted either from the LRN queue or enroute to the queue. 
These intercepted messages arc then sent to the Screening Board printer LRN for 
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printing. 3 Messages sent to the Screening Board are then individually examined by 
members of the board to determine further action. Further actions may include: [Ref. 
5: p.351 

• delivery by other means (i.e. courier, mail) 

• immediate reentry in NAVCOMPARS for broadcast 

• holding for reentry when queue conditions warrant 

A more detailed explanation of ZYB intercept modes and message reentry options 
is provided in the following sections. 

D. ADMINISTRATIVE TRAFFIC INTERCEPT MODES 

Removal of administrative traffic from NAVCOMPARS is performed by tw’o dif- 
ferent methods; an alternate routing (altroute) or a redirect. 

An altroute command is used to remove messages which are already queued on a 
LRN awaiting transmission. A redirect command is used to divert messages from a 
LRN which may be backlogged or non-operational due to equipment malfunctions or 
outages. [Ref. 5: p.28,p.35] 

1. ZYB Altroute Mode - AM Command 

The AM altroute is designed to remove existing administrative traffic from a 
specified LRN queue. In NAVCOMPARS Release 11.0 the specified LRN must be a 
broadcast type; in the upcoming Release 12.0 the LRN can be broadcast, full period, 
dedicated or CUDIXS.4 See Figure 2 on page 8. [Ref. 4: p.3; Ref. 6] 

The AM command is applicable for Immediate precedence messages and below. 
For example, an altroute of Immediate administrative traffic will also result in the 
altrouting of Priority and Routine traffic. 

Upon completion of the LRN purge the AM command will automatically de- 
lete. 



3 The Screening Board LRN is also the final destination for a Screening Board altroute and 
redirect function. The Screening Board functions are similar to an Administrative Screen except 
that all messages, whether operational or administrative in nature, are affected. 

4 CUDIXS, the Common User Digital Information Exchange System, is a communications 
link between a shore communication element and fleet units, using UHF satellites. CUDIXS can 
serve up to sixty properly equipped units using a polling scheme for transmission and reception 
order. 
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Figure 2. AM Command - NAVCOMPARS Release 11.0 and 12.0 



2. ZYB Redirect Mode - ADM Command 

The ADM command is used by the system operator to prevent deliver}' of ZYB 
designated messages to a specified LRN. Initiation of the command will direct qualify- 
ing messages from the original LRN to the Screening Board printer.^ See figure 3 on 
page 9. The precedence rules mentioned above for the AM command are also applicable 
for the ADM command. 

Unlike the AM command the ADM command must be manually terminated by 
the system operator. [Ref. 4: p.2] 



5 The Screening Board printer is the only allowed destination LRN currently used with 
NAVCOMPARS Release 11.0. Release 12.0 will incorporate additional destination LRN s when 
installed. 
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Figure 3. ADM Command - NAVCOMPARS Release 11.0 and 12.0 



3. Combination AM/ADM Command Usage 

In addition to being used separately the AM and ADM commands can be used 
simultaneously on the same source LRN. Operating in this mode the ADM command 
will direct newly arriving traffic to the Screening Board LRN while the AM command 
clears the specified source LRN queue of existing administrative messages. As men- 
tioned above, the AM command will automatically delete when the source LRN is 
purged of qualifying messages. The ADM command will require operator action for 
command removal. 
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E. MESSAGE REENTRY MODES 

Messages that have been altrouted or redirected to the Screening Board printer as 
a result of an administrative intercept must be screened to determine the next step in 
processing. At this point the individual message can either be delivered by other means 
or reentered into the system immediately or later, depending on queue conditions. 

Reentry of intercepted messages into the system can be achieved either through the 
intervention of a system operator at a Command Video Data Terminal (VDT), the cre- 
ation of a reentry tape, or the use of reentry altroutes. (Ref. 7: pp. 71-72; Ref. 4: p.4] 

1. VDT Initiated Message Reentry 

Within NAVCOMPARS, the Message Processing Subsystem (MPS) performs 
message analysis and VDT interface. The software module used for VDT interface is 
MPSVC. By using MPSVC and a VDT, it is possible to reenter intercepted adminis- 
trative messages using SVC commands. Two SVC commands are used for reentering 
intercepted messages: SBR and SBO (Ref. 8: p.7 1]. 

The use of the SBR command will requeue the message to the original LRN for 
transmission. In the event that another administrative altroute is performed these re- 
queued messages will again be intercepted. 

The SBO command is similar to the SBR command except that it will override 
any administrative altroute which takes place while the requeued message awaits trans- 
mission. [Ref. 9: p. 164] 

2. Message Reentry Tape 

An alternate method of reentry is accomplished through the creation of a re- 
entry tape using an off-line program. This program will extract identified administrative 
messages from the journal tape, reformat the messages appropriately, and then write 
them to a reentry tape. The system operator can then input the messages back into 
NAVCOMPARS using the reentry tape. 

3. Reentry Altroutes 

Intercepted messages can also be reentered from the Screening Board using re- 
entry altroutes. The reentry altroutes include: 

• channel reentry 

• short title reentry 

• routing indicator reentry 

• count reentry 
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Reentry altroutes return intercepted messages to the system if the specified 
precedence range and subject parameter requirements are met. Channel reentry returns 
to the source LRN messages which meet the precedence and destination channel re- 
quirements. Short title and routing indicator reentry commands are similar to the 
channel reentry, with the message short title and routing indicator being the second 
specified parameter. Count reentry differs slightly; the parameters specified by this 
command are the precedence range and number of messages to be reentered. Any mes- 
sage meeting the criteria of the selected reentry altroute will be requeued for trans- 
mission by the system. [Ref. 7: pp. 45-47] 



11 



III. ADMINISTRATIVE MESSAGE INTERCEPT IMPLEMENTATION 

STRATEGIES 



A. INTRODUCTION 

The use of an administrative message intercept to alleviate a broadcast queue 
buildup is only one of many traffic management options available to the 
XAVCOMPARS manager. The decision to invoke an intercept command should take 
into account many factors and considerations. Among these factors are the current 
operational situation (external factors), XAVCOMPARS system status (internal fac- 
tors), and the transmission medium in use. In this chapter the following factors will be 
addressed: 

1. External Factors 

2. Internal Factors 

3. Transmission Considerations 

4. Proposed Strategies 

B. EXTERNAL FACTORS 

When forming decisions on traffic management options the systems manager must 
take into account factors external to the XAVCOMPARS. These factors may have 
some bearing on what option the manager chooses to pursue. Factors to consider in- 
clude: 

1. Time 

2. Types of Users 

3. Exercise Conditions 

4. World Events 

1. Time 

Time factors to be considered include the time of day and the day of the week. 
The message releasing rates of users within a XAVCAMS's COMMAREA may show 
some sort of pattern over a period of twenty-four hours. For example, given that most 
messages are written during a normal working day, it may develop that these messages 
will enter XAVCOMPARS late afternoon or early evening local time, creating a higher 
traffic arrival rate. This proposed scenario combined with an already congested 
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NAVCOMPARS suggests imminent difficulties for system managers and operators. 
Trends such as these requires an operator's attention. 

The day of the week has also shown cyclic traffic patterns. Comparing traffic 
conditions shows that Wednesday through Friday are generally the heaviest load days, 
concurrent with the end of the workweek. Considering these cycles may aid a decision 
maker in forecasting a possible drop or increase in traffic arrival rates. [Ref. 5: p.37] 

2. Types of Users 

Each Naval Communication Area Master Station (NAVCAMS) is responsible 
for communications within a geographical area [Ref. 3: p.IV-1). A systems manager 
should know both the number and type of users within its Communication Area 
(COMMA REA); using this information enables the manager to better judge the poten- 
tial for traffic loading. For example, the arrival of multiple Carrier Battle Groups 
(CVBG) into a COMM AREA presents many factors to be considered. The increase in 
the total number of fleet units will undoubtedly increase message traffic arrival. An alert 
NAVCAMS should have overload circuits ready or arranged for to handle expected in- 
creases. Additionally, the commands controlling these units will generate additional high 
precedence traffic. Again, this may warrant additional overloads. [Ref. 5: p.37] 

3. Exercise Conditions 

The operational schedule of users within a COMMAREA should also be con- 
sidered. The conducting of exercises will increase message traffic arrival rates as coor- 
dination takes place. This increase will continue during the actual exercise and will 
probably not lessen until the exercise is well over. 

4. World Events 

World events can usually be expected to affect message traffic loading also. The 
outbreak of conflict in a NAVCAMS's COMMAREA, whether directly or indirectly 
involving U.S. forces, will increase communication activity as reports and observations 
are sent to command and control centers. Few such outbreaks occur instantaneously; 
the system manager should be aware of potential areas and the possible effects on traffic. 

C. INTERNAL FACTORS 

In addition to external factors a NAVCOMPARS operator must closely monitor the 
equipment and assets available to him or her. Keeping an overall picture of the system's 
parameters should enable the watch teams to forecast any inhouse problems short of 
catastrophic equipment failure. 
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Inherent in NAVCOMPARS are system status displays which are printable in hard 
copy form. These reports are: 

• Input Queue Summary Report 

• Output Queue Summary Report 

• Data Pattern Directory Report 

• CUDIXS Output Summary Report 

• Intercept File Queue Report 

• System Queue Summary Report 

Timely usage of the above reports^ should enable the operator to identify trends, po- 
tential backlog situations, or any unusual problems. 

In addition to the hard copy reports, queue status can also be obtained from: 

• Computer Operator console typeouts, both unsolicited and initiated 

• VDT Display 

• Teletype Logs 

Console typeouts appear as the result of computer detected conditions; typeouts are 
also the result of operator initiated requests. Example typeouts include reached queue 
limits, queue overflow, input/output errors, or imminent storage wraparound. Com- 
mand VDT status displays can also achieve similar results as the hard copy reports 
mentioned above. Teletype logs are LRN-oriented; typeouts of this type indicate com- 
puter detected conditions at specific channel logs. 

Additional system status indicators are the Output Queue Profile Reports: 
NCQPROS and NCQPROT. These background programs available on 90/60 
computer-equipped systems provide profile data for each message on a selected LRN 
output queue. NCQPROS provides printed output data in ascending order by originator 
short title. NCQPROT provides profile data on a queue by message. [Ref. 5: pp. 13-25] 

D. TRANSMISSION CONSIDERATIONS 

In addition to NAVCOMPARS' internal system status reports and the external 
considerations, the system manager must consider the transmission medium being used. 
As stated in Chapter two, the Fleet Broadcast is primarily carried via satellite on one of 
the Fleet Satellite Broadcast systems, or it is carried using High Frequency radio 

6 For a more detailed explanation of the above listed reports see NAVTASC Document No. 
15X7001 OM-02C, NAVCOMPARS Computer Operation Manual. 
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communications. When operating in either transmission mode, the operator must 
understand the nuances of each of the individual systems. 

The primary difference between HF and satellite communication is the frequencies 
used. Satellite communications typically operate in Ultra High Frequency (UHF) (300 
Mhz-3Ghz), Super High Frequency (SHF) (3Ghz-30Ghz), or in a combination of UHF 
and SHF (i.e. SHF uplink, UHF downlink). The particular satellite constellation in use 
by the NAVCAMS will determine the applicable frequency range. HF systems operate 
in the 3 Mhz - 30 Mhz frequency range. (Ref. 1: p.56] 

The chief disadvantage of HF communications is the susceptibility of radio wave in 
this range to attenuation and atmospheric disturbances. Maximum Useable Frequency 
(MUF) and Lowest Useable Frequency (LUF) are concepts used in understanding 
ionization effects on HF propagation. The time of day, placement of the moon, season 
of the year, latitude of the transmission, presence of sunspots, or meteor showers, indi- 
vidually or in combination, all affect the probability of successful HF communication. 
The above factors are all contributors to atmospheric ionization; this ionization can lead 
to HF attenuation by absorption. To ensure satisfactory HF communications both the 
sender and the receiver of an HF signal will have to display a fair amount of frequency 
agility to stay below MUF and above LUF. [Ref. 10: pp. 11-1 - 11-11] 

Because of HF attenuation problems, prudent practice may require the activation 
of additional rerun channels on the Fleet Broadcast. These channels, run in combination 
with common or type channels, would increase the probability of receiving all messages 
on the fleet unit should a message or messages be unreadable due to atmospheric con- 
ditions. 

E. PROPOSED STRATEGIES 

As mentioned in Chapter One, Commander, Naval Telecommunications Systems 
Command (CNTC) promulgated proposed thresholds for the implementation of an ad- 
ministrative message intercept. These thresholds were to be recommended to the Fleet 
Commander in Chiefs (FLTCINCs) [Ref. 11]. See Table 1 on page 16 for a listing of 
the proposed thresholds. 

COMNAVTELCOM also solicited comments and/or recommendations concerning 
the proposed thresholds. In this section the responses from each of the message ad- 
dressees will be presented. 
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Table 1. COMNAVTELCOM PROPOSED IMPLEMENTATION STRATE- 
GIES 



QUEUE BACKLOG 


ACTION 


70 


Analyze to determine if specific units can be brought 
up on special CUDIXS to clear single addee messages. 


175 


Implement admin message intercept for affected 
broadcast channels. 


50 


Commence reentering diverted messages. 



1. NAVCOMMSTA Stockton CA 

The comments from NAVCOMMSTA Stockton were generally negative con- 
cerning the proposed threshold limits. The primary comment was that a standard traffic 
threshold would restrict effective broadcast management by not allowing the operators 
onhand to exercise real-time decision making. The need to consider operational tempo 
and requirements was also emphasized. [Ref. 12] 

2. NAVCAMS EASTERN PACIFIC Honolulu HI 

The response from NAVCAMS EASTPAC generally paralleled 
NAVCOMMSTA Stockton's response. The response again emphasized that the 
uniqueness of each situation, in terms of operational requirements and the operating 
environment, required flexibility which would be reduced with the promulgation of 
standard thresholds. 

The message from NAVCAMS EASTPAC provided two alternatives, one for a 
satellite environment and one for operating in a HF environment. The threshold limits 
are provided in Table 2 on page 17 and Table 3 on page 17. 

The reasoning behind the different thresholds is that operating in HF differs 
from operating by satellite. The quality of a HF signal, as mentioned in previous 
sections, is heavily dependent on the environment and usually requires the activation of 
rerun channels to ensure greater probability of message reception. By activating an ad- 
ministrative intercept first, the requirement for fleet units to secure rerun channels in 
order to receive newly activated overload channels is delayed as long as possible. [Ref. 
13] 

3. NAVCAMS ATLANTIC Norfolk VA 

NAVCAMS LANT's response to the CNTC request was also negative towards 
the use of administrative intercepts. NAVCAMS LANT suggests the following system, 
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Table 2. HIGH FREQUENCY ENVIRONMENT THRESHOLDS - NAVCAMS 
EASTPAC 



QUEUE BACKLOG 


ACTION 


75 


Analyze Queue profiles to determine specific reasons 
for backlog. Try to reduce backlog with various man- 
agement options, less overload activation or admin in- 
tercept. 


100 


Invoke administrative intercept to the precedence level 
necessary to promote timely delivery of operational 
traffic. 


175 


Activate Broadcast overload channel(s). 


20 


Reenter intercepted messages. When all the messages 
have been reentered, revoke the intercept(s). 



Table 3. SATELLITE ENVIRONMENT THRESHOLDS - NAVCAMS 
EASTPAC 



QUEUE BACKLOG 


ACTION 


75 


Analyze queue profiles to determine specific reasons for 
backlog. Try to reduce backlog with various manage- 
ment options, less overload activation or admin inter- 
cept. 


175 


Invoke administrative intercept to the precedence level 
necessary to promote timely delivery of operational 
traffic. 


100 


Activate Broadcast overload channel(s). 


20 


Reenter intercepted messages. When all the messages 
have been reentered, revoke the intercept(s). 



when combined with active evaluation of the broadcast backlog and real world opera- 
tional conditions, to be more effective than the CNTC proposed thresholds: 

• Prompt activation of overload channels, if not in HF environment. 

• Review queue profiles on various channels and reduce broadcast queue by sending 
single addressee messages to special CUDIXS termination.? 



7 Using Queue Profiles allows the NAVCOMPARS manager to review messages held in 
queue for an output channel. By inspecting the profile the manager may identify a fleet unit which 
has a high number of messages slated for delivery. With this information the manager can altroute 
those messages through alternate delivery means (i.e. CUDIXS). 
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• Activate RCS overflow for high speed input lines. This removes lower precedence 

traffic onto an overflow tape for later reentry using controlled automatic methods. 

• Final alternative, activate TPS intercept for routine messages. 

NAVCAMS LANT also addresses the manpower efficiency of administrative 
intercepts as well as the need for a magnetic tape store and recall feature. These issues 
will be addressed in following sections. [Ref. 14} 

4. NAVCAMS WESTERN PACIFIC Guam 

The response from NAVCAMS WESTPAC was similar to that of NAVCAMS 
EASTPAC. Similar points concerning the lack of flexibility from a standard threshold 
and the need for real-time comprehensive situational analysis were raised. 

NAVCAMS WESTPAC also highlighted the requirement for a standard which 
addressed HF and satellite communications individually. The reasoning again centered 
on the fact that the success of HF communications is heavily dependent on the current 
environmental conditions; because of this dependency, fleet units must configure to re- 
ceive rerun channels, in addition to their common and type channels, to ensure highest 
probability of receiving all messages. See Table 4 on page 19 and Table 5 on page 19 
for proposed thresholds. [Ref. 15] 

5. NAVCAMS MEDITERRANEAN Naples Italy 

NAVCAMS MED generally concurred with the responses mentioned above. 
Again, the need to fully utilize the talents and experience of on-scene personnel was 
emphasized. A comment was also made that the imposition of standard thresholds 
would reduce flexibility and stifle initiative of the Broadcast Control Authority (BCA). 

There were no proposed threshold limits but it was mentioned that NAVCAMS 
MED procedures called for activating overload channels when broadcast queues reached 
60 to 70 messages. There was no mention of differences between operating in a HF or 
satellite environment. [Ref. 16] 

6. Naval Telecommunications Systems Integration Center 

The Naval Telecommunications Systems Integration Center (NAVTELSYSIC) 
was also solicited for comments and/or recommendations concerning the proposed 
thresholds; NAVTELSYSIC currently serves as the NAVY's telecommunication certif- 
ication facility [Ref. 3: p. II 1-2]. 

The comments submitted by NAVTELSYSIC stated that the thresholds pro- 
posed conflicted with the numbers listed in REF. 3 with respect to the activation of 
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Table 4. HIGH FREQUENCY ENVIRONMENT THRESHOLDS - NAVCAMS 
WESTPAC 



QUEUE BACKLOG 


ACTION 


70 


Analyze. Implement special management actions (ac- 
tivate HF RFCS Termination). 


100 


Implement admin intercepts. 


150 


Commence overload activation process if conditions 
allow. 


50 


Reenter intercepted admin messages. 



Table 5. SATELLITE ENVIRONMENT THRESHOLDS - NAVCAMS 
WESTPAC 



70 


Analyze. Implement special management actions 
(Special CUDIXS termination). 


150 


Implement admin intercepts. 


100 


Commence overload activation process. 


50 


Reenter intercepted admin messages 



overload channels. The Current FOTP instruction calls for the activation of overloads 
at a queue backlog of 150 messages. 

NAVTELSYSYIC also recommended that the individual NAVCAMS be al- 
lowed to establish their own implementation thresholds for administrative intercepts. 
[Ref. 17] 

7. Response Summary 

The responses generated by CNTC's request for comments and/or recommen- 
dations had many common points. Areas in common dealt with the effect of standard 
guidance on organizational relationships and decision making, the need for more envi- 
ronment oriented considerations, and the perceived design deficiencies of the adminis- 
trative message intercept. Another common thread that ran through the solicited 
responses was that queue levels through NAVCOMPARS are used as the most basic 
indicator of the current system status. Although the actual numbers varied, the general 
rule to success was to keep a queue level below a selected level. 

Many comments were made concerning the effect of standard thresholds on the 
organizational relationships between the FLTCINCs and the individual NAVCAMS. 
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The FLTCINCs, as operational commanders, exercise authoritative control over the 
communication assets within their geographical area of control [Ref. 3: p.V-2]. The is- 
suance of CNTC guidance is perceived as an erosion of this operational authority. 

Decision making issues were also raised; specifically, that the guidance failed to 
take into account the dynamic nature of the operating environment. Additional com- 
ments were that the experience and talents of on-scene personnel were not fully utilized 
when operating under such guidance. It was felt that operators on station could more 
adequately address an increasing queue problem by working with all resources available 
at the NAVCAMs, rather then by invoking a static set of procedures. 

The need for HF and satellite environment considerations was also highlighted. 
The guidance failed to consider the differences when operating with either HF or satel- 
lite. 

The effectiveness and efficiency of administrative message intercepts were also 
questioned. The comment was made that the intercept was manpower intensive due to 
the reentry procedures; this is critical with the current and future state of Naval man- 
ning. The need for a magnetic tape store and recall feature was mentioned; this would 
enable the operators to reenter intercepted messages by automatic means when queue 
levels permit. 

As mentioned above, queue levels are seen by both CNTC and the 
NAVCAMSs, as serving as a solid measure of system status. Since this appears to be 
the case throughout the Naval Telecommunications System (NTS), this research will 
also utilize queue levels as a status indicator on the simulation model. 



20 



IV. COMPUTER SIMULATION METHODOLOGY 



A. INTRODUCTION 

In this chapter, an overview of simulation will be presented, followed by an intro- 
duction to General Purpose Simulation System (GPSS) V. The final sections will pertain 
to the actual model of simulation used for this research. 

B. AN OVERVIEW TO SIMULATION 

It often turns out that it is not possible to develop analytical models for queueing 
systems. This can be due to the characteristics of the input or service mechanisms, 
the complexity of system design, the nature of the queue discipline, or combinations 
of the above [Ref. 18: p.455J. 

The above quotation by Gross and Harris lists the possible reasons or combinations 
of reasons why simulation might serve -as an adequate representation of an actual 
queueing system. Emphasis is placed on adequate. However, simulation is experiment- 
ing through the use of changing parameters; because of this, simulation can be subject 
to the same limitations of any experimentation. Limitations may include the validity of 
any inferences or assumptions made; this idea must be kept in mind throughout the 
simulation process. 

The execution of a simulation model can be divided into three phases: 

• Data Generation 

• Bookkeeping 

• Output Analysis 

Data generation is the creation of customers, the subject of the transaction. The creation 
of customers can be multiphased; the first phase is the actual generation of the subject 
customer. The second phase is the assignment of attributes to the customer, this is con- 
ditional on the particular simulation model in use since a customer may have many at- 
tributes or none at all. 

Bookkeeping is the gathering of measurements as the simulation model is run. 
Measurements may include the arrival and departure of each customer, the times in- 
volved in each significant part of the simulation, and the number of customers utilizing 
these significant sections of the simulation. 



21 



The third and final phase is output analysis. Using the data provided by the book- 
keeping phase, measurements are generated for analysis. Typical measurements and re- 
sults may include average queue size, average time in queue, idle time, or average waiting 
time. [Ref. 18: pp.456-469] 

Figure 4 on page 23 provides a diagram showing the three phases of simulation. 
Note the recursive feature between the Data Generation phase and the Bookkeeping 
phase; this represents the repetitive runs with compilation of data for the Output Anal- 
ysis phase. 

C. GENERAL PURPOSE SIMULATION SYSTEM (GPSS) V 

GPSS is a block diagrammatic simulation language which uses command operations 
to define a system structure [Ref. 18: p.471[. The fundamental element in GPSS is the 
entity; entities are designed to perform a variety of functions relative to the type of entity 
that it is. The most frequently used entities are [Ref. 19: p.7]: 

• transactions 

• blocks 

• facilities 

• storage 

• queue 

• logical switches 

• boolean variables 

Transactions are the principal items of movement within a simulated model; they 
can be created or destroyed dependent upon the model requirements. Transactions can 
also be assigned up to 1020 attributes; through the use of these attributes, it is possible 
to make each individual transaction somewhat unique. 

Blocks are used to perform command operations which were described when a sys- 
tem was analyzed. Blocks may perform four basic events: 

• creation and destruction of a transaction 

• alteration of an entity's numerical attribute 

• transaction delay consistent with simulated action 

• model flow alteration 

Facilities are used to represent equipment; a facility may be used to simulate the 
process of a cashier operating a grocery check-out stand or any process in a model which 
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Figure 4. Three Phases of System Simulation 

acts as a server. It should be noted that only one transaction may occupy a facility at 
a given time. 

Parallel processing equipment is represented using storages. Storages can be used 
to represent the maximum capacity of a room or the maximum storage available on a 
magnetic tape unit. 

Since facilities emulate single servers and storages have some set maximum capacity, 
transactions may be delayed awaiting a facility's process or a storage's availability. In 
this event, a transaction is held in queue; these transactions will be held until the facility 
or storage become available. 

Logical switches arc used to block or divert traffic dependent on the value of the 
switch. Transactions can also be utilized to set, reset, or invert a switch. 

Boolean variables can be used to make decisions based on numerous values; for ex- 
ample. any specific attribute of a transaction can be used as a basis for a decision using 
some sort of operator. Example operators include conditional, boolean, and logical at- 
tributes. [Ref. 19: pp.5-7] 

To aid in the generation of output most of the above mentioned entities create and 
maintain their own statistics. The queue entity, for example, gathers queue length, av- 
erage time in queue, total number of entries, average time per transaction spent in 
queue, and more. For a more detailed explanation of each entity and it's statistics, the 
reader must refer to Ref. 19 or Ref. 20. 

See Figure 5 on page 24 for an illustration of a GPSS block diagram for a single 
server queue model. In this single server simulation a transaction is created in the 
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Figure 5. Generic GPSS Simulation Model (Single Server Queue Model) 

generate entity. Following generation the transaction enters a queue block with 
subsequent entry into a seize block. The queue block is entered to simulate a line of 
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transactions awaiting the use of the following facility; the use of the queue also generates 
valuable statistics, as mentioned above. The seize block engages a specified facility to 
simulate some action taking place; once the facility is seized the transaction is allowed 
to leave the queue via the depart block. To generate a service time for the transaction 
GPSS uses the advance block; the advance block generates a delay time comparable to a 
service time. Upon completion of the delay time the transaction is released for further 
processing. The final block is the terminate block; it is in this block that the transaction 
is destroyed. 

D. SIMULATION MODEL DESIGN 

1. Simulation Model Foundation 

In Glenn's research on administrative message schemes he states the following 
regarding the Fleet Broadcast: 

. . . Broadcast can be looked upon as 15 parallel, nonidentical M/M/1 transmission 
facilities. Each channel has unique message arrival and service rates and is assumed 
to be a single service supplying its subscribers with the message traffic it transmits 
[Ref. 21: p.43J. 

Glenn later states, 

. . . final and most detailed model definition can be viewed as approximately seven 
parallel nonidentical facilities which would correspond with the number of first run 
channels, regular and overload, that are used [Ref. 21: p.43]. 

For the purpose of simulation it will be assumed that Glenn's proposals are 
valid. With this in mind, the idea that each output channel is a single server will serve 
as the basis for this research's model. 

See Figure 6 on page 26 for an illustration of the system model. 

2. Simulation Model Limitations 

As explained in Chapter Two, the activation of an administrative intercept re- 
sults in either the altrouting of messages in queue on the output channel, or the redi- 
recting of newly arriving messages from the selected channel. The action performed is 
dependent on the mode chosen by the system manager. In modeling the AM command 
feature the simulation package would be required to screen messages already held in 
queue to identify ZYB flagged messages for removal. Unfortunately, this capability does 
not exist with GPSS and prevents the author from modeling the AM intercept or the 
combination AM/ADM intercept. The decision to continue using GPSS was based on 
two reasons; one, GPSS's ease of use, and two, that the modeling of the ADM feature 
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Figure 6. Fleet Broadcast - Simplified Single Server Model 



would qualitatively show the intercept effects that the author considered pertinent to the 
research. 

The author also wishes to reemphasize that the results given are qualitative in 
nature. To validate the quantitative results of the simulation model would require re- 
sources not available at the time of the research (i.e. historical analytical data, actual 
NAVCOMPARS operation time under experimental conditions). 

3. ADM Model Design 

The single server model proposed in Ref. 21 is based on a standard teletype 
transmission circuit operating at seventy-five baud. To simulate this model using GPSS 
will require the following features: 

• transaction generation and termination 

• queue entrance and departure 

• simulation of transmission time 

• ADM intercept capability 

Transaction generation and termination is easily accomplished using the GPSS 
commands generate and terminate. The generate command will simulate message arrival 
at a desired rate; this is the first phase of generation mentioned above. The second 
phase, the assignment of attributes, is accomplished using three assign commands. The 
three attributes to be used are message precedence (routine, priority, immediate), 
administrative operational designation, and message length in characters. Note that 
both the simulated message arrival rates and attributes can be varied to simulate desired 
conditions; these options will be used to demonstrate the model features. 
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Queue entrance and departure is simulated through use of the queue and depart 
commands. Use of the queue command produces useful statistics mentioned above. 

Simulation of transmission time is done using the advance command. Using 
eight bits per character, 8 multiplied by the individual message length gives the message 
length in bits. Dividing this value by the capacity of the transmission circuit gives 
transmission time; the transmission capacity used was seventy-five baud. [Ref. 22: 
pp. 343-345] 

The simulation of an ADM command is done using multiple test commands. 
The first test command is used as a trigger that simulates a redirect when the queue level 
reaches a certain level. Once a redirect is started the second and third test commands 
check for message type (administrative or operational) and precedence respectively. See 
Appendix B, Simulation Model Specifications, for the actual GPSS code and an accom- 
panying flow chart showing diagrammatic model flow. 



8 Actual bits per message character is 7.42 for Baudot code TTY's [Ref. 22: p.342]. This is 
rounded up to eight bits due to GPSS requirement for advance block values to be intergers [Ref. 
19: p.26|. 
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V. SIMULATION RESULTS AND ANALYSIS 



A. INTRODUCTION 

The purpose of a simulation model is to allow via experimentation understanding 
of the influence of different parameters and variables on system behavior. By varying 
these parameters it is hoped that the researcher can develop causal relationships which 
might prove helpful in understanding the simulated system as a whole. In this chapter 
the following sections are included: 

1. Simulation Model Test Variables 

2. Simulation Model Test Results and Discussion 

B. SIMULATION MODEL TEST VARIABLES 

As mentioned in the previous chapter, the simulation model used in this research is 
a representation of a single output channel on the Fleet Broadcast with the capability 
of activating an ADM altroute. Within this representation of the Fleet Broadcast 
channel, there are several parameters which can be manipulated to test the model under 
varying conditions. 

1. Model Variables 

In this simulation model there are two types of variables which can be con- 
trolled; the first variable types are the attributes assigned each individual message on 
generation by the generate/ assign block sequence. These variables are: 

• Message Precedence 

There are four message precedence levels in use in the NAVY: Routine, 
Priority, Immediate, and Flash (in increasing priority). Of these four, only three , 
Routine, Priority, and Immediate, can be categorized as administrative messages 
[Ref. 23: p.4-2]. To reflect this, message precedence is granted through the assign 
block using the relative distributions and a random number generator. The user 
has the ability to vary the distribution of each message precedence to reflect the 
precedence characteristics of any simulation test run. 

• Message Length 

Through the use of the second assign block it is possible to dictate the 
range of total characters per message. In this simulation model, character assign- 
ment is given by a continuous function with a user determined low end and high 
end number of characters per message. In Ref. 24 , CNTC's Semi-Annual Sum- 
mary of Naval Telecommunications Performance, the approximate average mes- 
sage length was 1962 characters; this figure was used as a rough indicator on where 
to start length variation. 
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• Ratio of Administrative to Operational Messages 

The designation of whether a message is administrative or operational is 
determined in the third and final assign block. By varying the percentage of ad- 
ministrative message traffic , the researcher can affect the ratio of administrative 
to operational traffic to determine if there are any effects on the measured outputs. 

The second variable type is external to the actual messages; these are related to 
the message mean arrival rates and the activation of the administrative intercept com- 
mand. 

• Message Arrival 

Message arrival can be manipulated in two manners; the first is by the 
setting of the mean time between message generation. This, in effect, is the con- 
trolling of the message mean arrival rate to the system. The second modification 
is accomplished by specifying a spread modifier about the mean time between 
message generation. Using this feature makes the arrival rate less constant and 
more realistic. 

• Administrative Intercept Command 

The activation of the administrative intercept command can also be modi- 
fied in two ways. First, the model can be executed with the intercept command 
being invoked at any specified queue level; in the actual GPSS code, the intercept 
command is set to activate when the output queue equals a user determined level. 
The second modification to the intercept command is precedence oriented; the user 
can set the model to intercept administrative messages at different precedence levels 
using lest blocks. 

2. Simulation Test Run Coding 

To identify the various simulation test runs, it was necessary to develop a means 
of differentiating between the runs. The coding scheme is illustrated in Figure 7 on page 
30. Test Run Designation is the identification number for the simulation run. Total 
Message Arrivals for 24 Hour Period is the cumulative total of messages to be generated 
by the simulation system. Message Interarrival Time Modifier (%) is the control of 
variance about the message mean interarrival time; message mean interarrival time is 
total seconds per day (86400) divided by the total messages per day. Administrative 
Messages (%) in Total Traffic indicates the percentage of total arriving messages that 
are administrative in nature. Queue Level at which Intercept is Activated is set by the 
user; Precedence of Administrative Messages Affected is also selected by the user. Two 
factors are not included in the coding scheme; these are the message precedence distrib- 
ution and message character ranges. It will be assumed that the message precedence 
distribution is 0.33 Routine, 0.33 Priority, and 0.33 Immediate, unless otherwise speci- 
fied; similarly, the message character range will be assumed to be 100-2500. The message 
character range is continuous and message character values assigned are distributed 
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Test #AA/BBBB/CC/DD/EEEZ 



Parameters: 

AA - Test Run Number Designation 
BBBB - Total Message Arrival for 24 Hour Period 
CC - Message Mean Interarrival Time Modifier (%) 
DD - Administrative Messages (%) in Total Traffic 
EEE - Queue Level at which Intercept is Activated 
Z - Precedence of Administrative Messages Affected 
(includes selected precedence and lower) 



Figure 7. Simulation Test Run Coding Scheme 

uniformly over the indicated range. Should test parameters for precedence distribution 
or message character range require alteration the new values will be indicated in the 
applicable section and on the resulting graphs. 

3. Simulation Test Run Results 

As mentioned in the previous chapter, the result of the simulation runs will be 
used for comparative analysis using graphs of the following factors: 

• Total Message Throughput 

• Output Channel Queue Level (noncumulative) 

• Total Administrative Messages Intercepted 

Additional graphs will also be used to further examine output characteristics. Preced- 
ence distribution of messages transmitted (throughput) will be provided with the indi- 
vidual cumulative precedence levels over the test period. The breakdown of 
administrative versus operational messages transmitted will also be provided. See 
Figure 8 on page 31 for an explanation of test graph terminology. 
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TEST GRAPH LEGEND** 



A. THROUGHPUT GRAPH 

1) THROUGHPUT - Messages transmitted (cumulative) 

2) QUEUE - Messages in queue (noncumulative) 

3) ADMIN - Administrative messages intercepted 

(cumulative) 

B. MESSAGE PRECEDENCE GRAPH 

1) ROUTINE - Routine messages transmitted (cumulative) 

2) PRIORITY - Priority messages transmitted (cumulative) 

3) IMMEDIATE - Immediate messages transmitted 

(cumulative) 

C. MESSAGE TYPE GRAPH 

1) ADMIN-XMIT - Administrative messages transmitted 

(cumulative) 

2) OPS-XMIT - Operational messages transmitted 

(cumulative) 

**-all graphs are based on a 24 hour run time with data 
generated every 2 hours. 



Figure 8. Test Graph Legend 
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C. SIMULATION MODEL TEST RESULTS AND DISCUSSION 

In this section the results of simulation test runs will be presented graphically. 

1. Message Precedence Distribution Variation 

In this set of simulation tests all parameters were held constant with the excep- 
tion of the precedence distributions. Three tests were conducted using the following 
precedence distributions: 

• #29 - 0.45 Routine, 0.40 Priority, 0.15 Immediate 

• #27 - 0.15 Routine, 0.40 Priority, 0.45 Immediate 

• #28 - 0.05 Routine, 0.40 Priority, 0.55 Immediate 

Average utilization for the system test runs, using average message arrival rate, divided 
by the average message service rate, is [Ref. 20: p.288]: 

• #29 - 1.31 

• #27 - 1.31 

• #28 - 1.32 

The results are presented in Figure 9 on page 33. 

From inspection of the results there appears to be no appreciable differences 
when using throughput, queue level, and intercepted administrative messages as meas- 
ures of performance. This is not completely surprising given that only the precedence 
distribution was altered. Keeping in mind that this is a preemptive system with higher 
precedence messages receiving first servicing, it can be hypothesized that the sequence 
of individual messages being processed changed when the distribution was altered. For 
example, in Test #28 with fifty-five percent Immediate and forty percent Priority mes- 
sages, it is hypothesized that the majority of Routine traffic is either in queue or has 
been intercepted if an administrative message altroute had been in effect. This hypoth- 
esis appears valid by examining the precedences of messages transmitted in Figure 10 
on page 34. The Routine messages in Test #28 are never transmitted due to their low 
priority. In Test #29 with only fifteen percent Immediate messages, there are more 
Routine messages processed through the system without preemption; this is illustrated 
in Figure 10 on page 34. 



32 



Data from "#29/800/25/30/1001" 




10 



HOUR 



20 



30 



Figure 9. Message Precedence Distribution Variation 
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Data from "#29/800/25/30/1001' 
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Figure 10. Precedences Transmitted - Tests #29, #27, #28 
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2. Message Length Variation 

The number of characters present in a message directly determines the trans- 
mission time required on the output channel assigned. In this test set, three runs were 
conducted using the following ranges: 

• #30 - 100-1500 characters per message 

• #6 - 100-2500 characters per message 

• #31 - 100-3500 characters per message 

The reader is again reminded that the character values assigned are uniformly distributed 
over the indicated continuous character range. 

The results from this set of tests, illustrated in Figure 1 1 on page 36, show dis- 
tinct differences in all three quantities measured. Precedences transmitted and message 
types transmitted are illustrated in Figure 12 on page 37 and Figure 13 on page 38. 
At the lowest range, in Test #30, throughput was maximized with few messages held in 
queue; because of this, it was not necessary to activate an administrative message inter- 
cept. Precedences transmitted in Test #30 showed corresponding increases at all levels. 
There was also an appreciable number of administrative messages transmitted. Widen- 
ing the range to 100-2500 characters in Test #6 shows a drop in throughput with a 
buildup in queue level. Messages of Routine precedence were not transmitted until hour 
ten; this is the approximate point where the intercept was activated. The activation re- 
duced message arrival into the queue allowing Routine messages in queue the opportu- 
nity to be transmitted. It should also be noted that the administrative message intercept 
in this character range aided in lowering the queue level when activated. Test #31, at 
100-3500 characters, illustrates an appreciable drop in throughput with increases in both 
queue level and intercepted administrative messages. Lower priority Routine messages 
had little possibility of being transmitted; correspondingly, both administrative and op- 
erational messages transmitted decreased. In this run the activation of the intercept 
showed little effect in lowering queue level. With the increase in message characters it 
is felt that the benefits of the intercept are reduced by the slowdown in message proc- 
essing. 

Results of these tests show that the number of characters in arriving messages 
affects the message throughput and lessens the effectiveness of the adminstrative inter- 
cept in reducing queue level as the number of average message characters increases. 
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Figure 11. Message Length Variation 
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Figure 12. Precedences Transmitted - Test #30, #6, #31 
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Data from "#30/800/25/30/1001" 
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Figure 13. Message Types Transmitted - Test #30, #6, #31 
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3. Message Type Variation 

The effectiveness of an administrative message intercept is directly related to the 
percentage of administrative messages in the arriving traffic. This effect was demon- 
strated using the following variations in percentage administrative traffic: 

• #4 - 20% 

• #5 - 25% 

• #6 - 30% 

• #7 - 35% 

• #8 - 40% 

• #9 - 45% 

The results of these test runs are illustrated in Figure 14 on page 40 and Figure 15 on 
page 41. Precedences transmitted during these tests are illustrated in Figure 16 on page 
42 and Figure 17 on page 43. Message types transmitted are illustrated in Figure 18 
on page 44 and Figure 19 on page 45. From observation, it is apparent that as per- 
centage administrative traffic increased so does the effectiveness of the intercept in re- 
ducing queue level. Additionally, this effectiveness leads to higher amounts of 
intercepted messages at the Screening Board printer. 

Precedences transmitted show decreasing numbers of Priority and Immediate 
traffic with increasing Routine messages being transmitted as the percentage adminis- 
trative traffic increases. The cause of this behavior is that an intercept of administrative 
messages while at a high percentage of administrative traffic, will remove all adminis- 
trative Priority and Immediate traffic. This decrease in higher precedence messages leads 
to the transmission of lower precedence traffic already held in queue. Administrative 
messages transmitted also show an increase in the Message Types Transmitted graph 
with operational messages decreasing. This is the result of the sheer increase of per- 
centage administrative traffic in each test run. Note, however, that once an intercept is 
activated the amount of administrative transmitted drops until finally no administrative 
traffic is transmitted. This would allow the possibility of higher throughput for opera- 
tional traffic; this is shown by the increased rate of operational messages transmitted. 
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Figure 14. Message Type Variation (a) 
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Data from "#7/800/25/35/1 001" 
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Figure 15. Message Type Variation (b) 
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Figure 16. Precedences Transmitted - Test #4, #5, #6 
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Data from "#7/800/25/35/1 001" 
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Figure 17. Precedences Transmitted - Test #7, #8, #9 
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Data from ”#4/800/25/20/1001" 
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Figure 18. Message Types Transmitted - Test #4, #5, #6 
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Figure 19. Message Types Transmitted - Test #7, #8, #9 
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4. Message Arrival Rate Variation 

In this phase of testing, simulations were conducted in two parts; the first part 
included variation of total messages arrived over a twenty-four hour period. The second 
part involved variations in the spread modifier about the mean interarrival time. 

a. Arrival Rate Variation 

This test sequence was conducted at the following daily arrival rates: 

• #6 - 800 messages per day 

• #1 - 1000 messages per day 

The results of the two runs are in Figure 20 on page 47. The results indicate two dif- 
ferences. The first difference is that the administrative message intercept requires an 
earlier activation; in this case, activation at six hours for 1000 messages per day and 
activation at ten hours for 800 messages per day. The second difference is that the 
higher arrival rate of Test #1 reduces the effectiveness of the intercept; the number of 
messages altrouted will not be sufficient enough to reduce the queue level. At the lower 
arrival rate, the intercept does aid in queue level reduction. 

b. Variation about the Mean Interarrival Time 

The testing in this set was conducted at the following percent variation 
about the mean interarrival time: 

• #15 - 10% 

• #16 - 20% 

• #17-25% 

• #18 - 30% 

• #19-40% 

• #20 - 50% 

From observation of Figure 21 on page 48 and Figure 22 on page 49, there is no ap- 
preciable difference. Inspection of the data from the Precedences Transmitted and the 
Message Types Transmitted also indicate no appreciable difference. The data shows 
minor variation of one or two messages at any given point during the run. This phe- 
nomena may be explained by the Law of Large Numbers which states that in a large 
sample, the probability is high that the sample mean is close to the mean of the parent 
population [Ref. 25: p.284]. In other words, given a parent population mean message 
interarrival time with a large sample size, the amount of variance (or in this case, spread 
modification) will have little effect in producing a sample mean interarrival time much 
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Figure 20. Message Interarrival Time Variation 

different from the parent population mean. This would explain why each graph appears 
almost identical regardless of the spread modification. 



47 



Data from "#15/800/1 0/30/1 001' 



5 

a. 





Figure 21. Message Interarriva! Time Spread Modifier Variation (a) 
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Figure 22. Message Interarrival Time Spread Modifier Variation (b) 
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5, Administrative Intercept Command Variation 

The administrative intercept command can be altered in two ways; the first 
method involves the timing of intercept activation. The second method involves the 
precedence level selected for the intercept. 

a. Administrative Intercept Command Activation 

The decision of when to activate an administrative altroute is dependent on 
what the system manager's definition of a congested queue is. In this set of simulations 
the message arrival rate was set at 1000 messages per day to rapidly congest the queue. 
For testing purposes, the following activation points were selected: 

• #1 - 100 messages in queue 

• #2-150 messages in queue 

• #3 - 200 messages in queue 

Note that the above tests were run at Immediate precedence and below. See Figure 23 
on page 51 for the test results. Precedences transmitted is shown in Figure 24 on page 
52. 

The first noticeable effect is that the earlier the command activation the 
lower the resultant queue size. While there is no reduction in queue size the intercept 
activation prevents the queue size from expanding further. In the previous section on 
message arrival rate, it was pointed out that at 1000 messages per day the activation of 
an intercept did not reduce a queue size but only helped control it. At a lower message 
arrival rate, the promptness of the intercept activation will determine the effectiveness 
of queue reduction. 

The Precedence Transmitted graph illustrates that the earlier activation of 
an intercept quickens the transmission of Routine messages already held in queue. 
These Routine messages would otherwise remain in queue while higher precedence 
messages get transmitted. 

The Message Type Transmitted graphs, shown in Figure 25 on page 53, 
show minor differences in adminstrative messages transmitted. The differences are due 
to the varying amounts of administrative messages allowed in queue prior to activation. 
For example, Test #3 with a late activation at 200 messages in queue, will accumulate 
more administrative traffic in queue prior to intercept activation. These messages are 
later transmitted after activation of the intercept. 
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Figure 23. Intercept Activation Level Variation 
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Figure 24. Precedences Transmitted - Test #1, #2, #3 
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Figure 25. Message Types Transmitted - Test #1, #2, #3 
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b. Administrative Intercept Precedence Variation 

This set of tests was conducted using a 0.33 Routine, 0.33 Priority, 0.33 
Immediate precedence distribution at S00 messages per day mean arrival rate, with in- 
tercept activation at a queue level of 100 messages. The test parameters are: 

• #10 - Routine precedence 

• #11 - Priority precedence and below’ 

• #12 - Immediate precedence and below 

The results, illustrated in Figure 26 on page 55 demonstrate that the pre- 
cedence level selected for the intercept will directly determine the effectiveness of the in- 
tercept. A low precedence selection will decrease the effectiveness of the intercept; 
conversely, a high precedence will increase intercept effectiveness. 

The Precedences Transmitted graph in Figure 27 on page 56 shows that an 
intercept set at a higher precedence frees more low r er precedence traffic from the queue. 
In essence, the operator is trading higher precedence administrative traffic for lower 
precedence operational traffic. 

Message Types Transmitted shown in Figure 28 on page 57 indicates a 
higher administrative transmission total at the low precedence intercept. In this case, 
the higher precedence administrative messages are blocking the lower precedence oper- 
ational traffic. 

6. Summary 

The results of the simulation tests demonstrate that the effectiveness of an ad- 
ministrative intercept is related to the specific characteristics of arriving messages. The 
specific characteristics include: 

• Precedence Distribution of Arriving Messages 

The distribution across the various precedence catagories affects the effec- 
tiveness of the intercept based upon the precedence level chosen for the altroute. 
For example, an administrative intercept of routine messages will have minimal ef- 
fect if the arriving traffic is primarily Priority or Immediate precedence. 

• Message Length 

The transmission time required for a message is directly related to the 
number of characters in the individual messages; traffic composed of messages with 
high average number of characters will move slower than traffic with a low average 
number of characters. Similarly, the longer transmission times will lead to higher 
queue levels. The advantage of an administrative intercept will be less apparent in 
traffic with a a higher average character count; the intercept may slow queue 
build-up, but most likely will not decrease the backlog. The average message length 
will also affect the precedence levels transmitted; at a high average character count 
the possibility of transmitting low r precedence traffic drops. 
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Figure 26. Intercept Precedence Level Variation 
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Figure 27. Precedences Transmitted - Test #10, #11, #12 
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Figure 28. Message Types Transmitted - Test #10. #11, #12 
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• Message Type 

The percentage of administrative messages in arriving traffic directly de- 
termines the effectiveness of any intercept. The activation of an intercept in a 
scenario with a high percentage of administrative messages will have marked effects 
on the queue levels while the activation in traffic with low percentage leads to a 
lessened effectiveness. 

• Message Interarrival Time 

The arrival rate of messages is directly related to the effectiveness of an 
administrative intercept. The effectiveness will run from high in a low message ar- 
rival rate to low in a high traffic arrival rate. Additionally, higher traffic rates will 
require prompt action from operators/managers since the queue build-up is more 
rapid. 

Variations about the mean interarrival time demonstrated no appreciable 
effects on throughput; as mentioned above, this can be explained by the Law of 
Large Numbers. 

The effectiveness of administrative intercepts is also related to the timeliness and 
scope of the activation command. These considerations are: 

• Command Activation 

The timeliness of activation may not increase the actual effectiveness of the 
intercept, but it may determine whether or not the queue reaches a critical satu- 
ration point. Earlier activation may aid a manager in controlling a potential 
backlog problem. Earlier activation may also help in freeing lower precedence op- 
erational traffic in queue. 

• Precedence Level 

The precedence level selected for use by the manager will control the scope 
of the intercept command. At higher precedence levels the command becomes 
much more inclusive. This can be consider a sensitivity adjustment of the intercept; 
this would allow the manager to more effectively tailor the intercept to the traffic 
situation. The key concept is that using administrative intercepts at higher pre- 
cedence levels frees the lower precedence operational traffic. 
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VI. ADMINISTRATIVE INTERCEPT CONSIDERATIONS 



A. INTRODUCTION 

The decision to activate an administrative intercept is a complicated one; it requires 
much more forethought than the simple observation of the queue level of an output 
channel on the Fleet Broadcast. It is proposed by the author that the decision on when 
activate an intercept is composed of two distinct phases; the first is the guidance and 
policy development phase. The second phase is the actual on-station decision making 
using the guidance and policy promulgated. These phases will be discussed in the fol- 
lowing sections. 

B. THE DEVELOPMENT OF GUIDANCE AND POLICY 

The decisions on how to utilize a tool like the administrative intercept are very 
complicated. In Glenn's research on methodology for evaluating the effectiveness of an 
administrative intercept he states that there are multiple performance attributes to be 
evaluated [Ref. 21: p.50]. He proposes that the decision process for actuating an inter- 
cept is composed of the attributes listed in Figure 29 on page 60 [Ref.21: p.52J. 

Note that the hierarchy of attributes Glenn suggests is applicable to the development 
and implementation of a new traffic management option. For a feature already installed 
in the fleet, like administrative intercept, the applicable attributes would be system ef- 
fectiveness, Navy acceptance, and cost to employ (not including initial costs). 

Utilizing these attributes the policy makers can, using Multiattribute Utility Analy- 
sis [Ref. 26] or the Analytical Hierarchy Process? [Ref. 27 and Ref. 28], assign a prefer- 
ence value by weighting the attributes individually. In this process the policy makers can 
directly influence the decision making process, emphasizing the factors deemed critical. 
For example, by weighting system effectiveness heavily, a policy can be generated which 
is tailored to ensure system effectiveness over the other choices. 

Upon completion of the attribute analysis, a policy with proposed thresholds and 
procedures can be promulgated to the operators and managers at the NAVCAMS. 

9 See Appendix C for a brief explanation of the concepts behind Multiattribute Utility Anal- 
ysis and the Analytical Hierarchy Process. 
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Figure 29. Hierarchy of Attributes 

C. ON-STATION DECISION MAKING 

Once a policy is promulgated it is the responsibility of the operators and managers 
to ensure that it is carried out. However, the perfect conditions under which the policy 
was generated may not exist at the user level; it is for this reason that the author re- 
commends that any policy regarding administrative intercept be advisory. The issuance 
of an advisory guidance vice a firm set of rules allows the operators to work effectively 
in even the most unpredictable set of circumstances. 

At the user level, any good decision making process must include all information 
available. The external factors and internal NAVCOY1PARS factors mentioned in 
Chapter III must be included. The transmission system in use also will be a factor in 
the process. The characteristics of the arriving message traffic was shown in the previ- 
ous chapter to be extremely influcncial in determining the relative effectiveness of an 
intercept action. All the above factors combined with the various intercept command 
variations (different activation levels, varied precedence levels) will impact heavily upon 
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the decision making process. The relationship emphasizing the interdependence of all 
these factors, is highlighted in Figure 30 on page 62. 

Using the above listed information, it is possible for the managers and operators, 
working within the guidance of CNTC, to reach a decision on intercept activation which 
would be both responsive and effective at the local level. See Figure 31 on page 63 for 
an illustration of the proposed process. The policy development is comprised of the se- 
veral steps; the first step is the determination of applicable criteria or attributes. Using 
either Multiattribute Utility Analysis, the Analytical Hierarchy Process, or any applica- 
ble analysis process, the criteria can then be evaluated with the end result being the 
generation of criterion for policy. It is then recommended that an advisory guidance, 
based on those criterion, be promulgated. The NAVCAMSs, using the advisory guid- 
ance, can then take into account all information held on-station and forge an activation 
decision which is influenced by both upper echelon policy and local communication 
conditions. 

It should be noted that this decision process can be readily adapted to other traffic 
management decisions. The factors to be considered, both at the policy making level 
and on-station, may require modification depending on the particular decision to be 
evaluated. 
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E - Effectiveness of an administrative intercept 

E = F(AA,BB,CC,DD,EE,XX,YY,ZZ) 

AA - Precedence Distribution 

BB - Message Length (avg) of Arriving Traffic 

CC - Percent Administrative Message 

DD - Message Arrival Rate 

EE - Intercept Command 

1) Queue level selected 

2) Precedence level selected 
XX - External Factors (Chapter III) 

YY - NAVCOMPARS Internal Factors (Chapter III) 
ZZ - Transmission Considerations (HF vs SAT) 



Figure 30. Considerations for Implementing an Administrative Intercept 
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Figure 31. Decision Making Process for Administrative Intercept 
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VII. CONCLUSIONS AND RECOMMENDATIONS 



A. FINDINGS 

The guidance promulgated by CNTC in Ref. 11 presents an activation scheme for 
an administrative message intercept based on Fleet Broadcast output channel queue 
backlog. Subsequent message reentry of intercepted message is also based on queue 
backlog level. 

The solicited responses from the individual NAVCAMS summarized in Chapter III, 
were for the most part negative. Frequent comment was made on the following issues: 

• the need for thresholds oriented with the particular Fleet Broadcast transmission 
means in use (HF/Satellite) 

• the effectiveness and efficiency of the administrative message intercept as a traffic 
management device in its present form 

• perceived erosion of traffic management decision making at the 
FLTCINCs/NAVCAMS level 

• disregard for on-station watchteam expertise 

• the failure of the CNTC threshold to take into account the special requirements 
and causes of each traffic congestion problem 

Based on the NAVCAMS's responses and the conducted research of this thesis it 
appears that the NAVCAMS's comments are generally well founded. Due to differences 
in HF and Satellite operation requirements it is imperative that there be specialized 
thresholds for working in each environment. It may also be necessary to develop 
thresholds for each individual NAVCAMS based on the local propagation conditions. 
The individual tailored thresholds should take into account the differing sequence on 
intercept activation steps (HF-intercept/overload versus Satellite-overload/intercept). 

The second item listed above questioned the most current configuration of the ad- 
ministrative intercept. As mentioned in Chapter II, the activation of an intercept results 
in the altrouting of qualifying messages to the Screening Board printer for further 
screening. This process would appear to be both equipment and manpower intemsive. 
The intercept results in additional printer requirements as well as the personnel required 
to review the messages by hand. Reentry requirements are also manpower intensive 
since it requires that the Service Clerk key individual messages for reentry into the 
NAVCOMPARS. One recommendation by NAVCAMS LANT, was that alternate 
routing to a magnetic tape storage unit be used in place of the Screening Board printer 
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(Ref. 14]. This recommendation fails to address message screening. Altrouting directly 
to a storage medium (i.e. magnetic tape or disk) without screening fails to remove mes- 
sages from the system; this type of altroute would only postpone reentry until queue 
levels permit. 

One improvement on the horizon is the Automatic Message Screening Subsystem 
(AMSS) scheduled for NAVCOMPARS Release 13.0 software (Ref. 6]. AMSS should 
improve the current Screening Board procedure by electronically allowing message 
screening by video terminals with the capability of on-line reentry of messages if desired 
[Ref 29]. Additionally, AMSS will reduce the requirement for message printing and 
sorting, and Service Clerk reentry procedures for intercepted messages. 

The final three points can be addressed as a group. The imposition of a firm 
threshold guidance by CNTC was felt, by the NAVCAMS, to reduce traffic management 
options. By virtue of being on-station it was felt that the watchteams would have a more 
complete "big picture" of the traffic situation in their individual COMM AREAs. The 
watchteams would also have more information on equipment resources and/or limita- 
tions, and be in direct communication with the end users, the fleet units. The 
watchteams would also, through the traffic monitoring capabilities of the 
NAVCOMPARS, be appraised on the characteristics of the arriving traffic. The char- 
acteristics listed in Figure 30 on page 62 of Chapter VI were shown, individually or in 
combination, to affect the effectiveness of an activated administrative intercept. 

Given this information on traffic characteristics, equipment resources, and the needs 
of the fleet units it appears that the NAVCAMS's watchteams, using their combined 
expertise and experience, would be better suited to judge when to activate an adminis- 
trative message intercept at the user level. 

This in a sense is a shift from an upper echelon controlled activation to a user con- 
trolled activation scheme. In Chapter VI, it is suggested that a two phase decision 
process be utilized. Using the two recommended phases would allow CNTC to empha- 
size its priorities, but at the same time allow the users, the NAVCAMS's, a certain 
amount of flexibility to deal with a dynamic environment. It is the conclusion of this 
thesis that such a process would be beneficial to all parties concerned. Through the use 
of this proposed scheme it is hoped the fleet units, the end users, can be assured timely 
delivery of vital message traffic. 
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B. POSSIBLE FUTURE TOPICS 

From the simulation test runs it was apparent that message characteristics can afTect 
message throughput. One characteristic, the percentage of administrative messages in 
arriving traffic, showed strong influence on the effectiveness of an administrative mes- 
sage intercept. In his research, Glenn states that fifty percent of all arriving traffic may 
be administrative in nature [Ref. 21: p.57]. If this were indeed the case it would appear 
that the effectiveness of an intercept is being held artificially low by the incorrect classi- 
fication of messages. CNTC is in the process of developing an policy where message 
originators will be required to classify a message as administrative or operational [Ref. 
30]. The current policy assumes that all messages are operational unless marked as ad- 
ministrative. Although the marking of both administrative and operational messages 
has no real effect in terms of message handling procedures, it is hoped that the origina- 
tors will be forced to more closely screen their messages before marking one as opera- 
tional. One possible research topic is to compare user's perceptions of what constitutes 
an administrative message or an operational message. Using this data and data from 
CNTC it may be possible to develop criteria to use in defining message categories. 

Another traffic characteristic which affected throughput was message length. By 
reducing message lengths throughput and speed of service should improve. Is there a 
way of decreasing average message length? Several recurring Navy messages have a set 
format which seems to reduce message length. Examples are Casualty Reports 
(CASREP) used for reporting equipment casualties or degradation and the NEURS 
(Navy Energy Usage Reporting System) report used for reporting fuel consumption and 
accounting. Both reports are format oriented and would seem to reduce message 
lengths. The possibility of increasing use of format messages and the potential gains in 
terms of throughput and speed of service should be investigated. 

With the increased use of Decision Support Systems (DSS) it may be possible to 
commence implementation in the Naval Telecommunications System. One possibility 
is the use of DSS with the AMSS; this would further decrease the need for manpower 
since the proposed AMSS requires experienced personnel to man the video terminals. 

The final proposed topic is related to the user level decision making criteria shown 
in Chapter VI. Given this wide set of variables, it may be possible to develop a detailed 
flowchart which can lead a user step-by-step to a valid activation decision or provide a 
foundation for DSS implementation. 
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APPENDIX A. NAVCOMPARS - AN OVERVIEW 



The Naval Communications Processing and Routing System (NAVCOMPARS) is 
an automated system which serves as an interface between the Naval Telecommuni- 
cation System (NTS) and the Defense Communication System (DCS). In this appendix, 
the following areas will be addressed: 

1. Functional Interface Areas 

2. NAVCOMPARS Subsystems 

A. FUNCTIONAL INTERFACE AREAS 

The NAVCOMPARS is comprised of eight functional interface areas which interact 
with the system processing actions. These areas include: 

1. Message Center (MSGCEN) 

2. Service Center (SVCEN) 

3. Fleet Center (FLTCEN) 

4. Computer Center (COMPCEN) 

5. Technical Control (TECHCTL) 

6. Receiver Site (RECSITE) 

7. Top Secret (TS) Control 

8. Operations Office (OPSOFF) 

1. Message Center (MSGCEN) 

The primary purpose of the MSGCEN is serving as the delivery and acceptance 
source for over-the-counter traffic. These services are provided for local users; local us- 
ers may include tenant commands and/or fleet units (when under "guard" or "protect" 
coverage by the NAVCAMS).lO The MSGCEN interfaces with the NAVCOMPARS 
using optical character readers (OCR), video data terminals (VDT), teletype (TTY), and 
medium-speed line printers! [Ref. 8: pp.3-8] 

10 "Guard" and 'Protect' are different levels of coverage provided by the NAVCAMS for the 
local users. "Protect" coverage means that the NAVCAMS only receives traffic for the local users; 
"guard" is s imil ar to "protect", but includes routing (extra copies and internal distribution) for the 
users. 
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2. Service Center (SVCEN) 

The SVCEN's main purpose is to service and/or correct messages which are re- 
jected by the system. The SVCEN also processes Broadcast Service Requests (BSR) for 
units requiring retransmission of missed or garbled messages. NAVCOMPARS inter- 
faces are through VDTs, line printers, teleprinters, and paper tape readers/punches. 
[Ref. 8: pp.8-11] 

3. Fleet Center (FLTCEN) 

The FLTCEN serves as the major terminal area for low speed communication 
channels; this responsibility entails monitoring and operating of active channels. Active 
channels include off-line and on-line quality terminations; off-line quality channels are 
not landline quality and require operator interaction to provide interface between the 
user and NAVCOMPARS. Typical operator interaction is visually proofing the message 
for mistakes and correct format, and men entering the message into the 
NAVCOMPARS using a paper tape reader. On-line channels are landline qualityil and 
interface directly with NAVCOMPARS; there is no operator interaction required. 

Additional FLTCEN duties include controlling and monitoring Fleet Broadcast 
channels. This control includes common, type, overload, and rerun channels. 

Hardware in the FLTCEN includes VDTs, teleprinters, 100 word per minute 
(WPM) channels, and paper tape readers. [Ref. 8: pp. 1 1-16] 

4. Computer Center (COMPCEN) 

The COMPCEN is the location for most of all the automatic data processing 
equipment comprising the NAVCOMPARS; it also serves as the interface between the 
NAVCOMPARS and DCS' Automatic Digital Information Network (AUTODIN). 
Responsibilities include actual NAVCOMPARS operation, data base maintenance, and 
report generation. 

Hardware includes computer consoles to control and monitor the entire system, 
medium-speed line printers, card readers, card punches, magnetic tape stations, and 
AUTODIN interface units. [Ref. 8: pp.20-23] 

5. Technical Control (TECHCTL) 

TECHCTL is the master switchboard and monitoring station for the 
NAVCOMPARS. TECHCTL uses landline or radiolinks with remotely located 

1 1 Landline quality is defined as a state where a transmission means is of high enough quality 
to equal the performance received on a land system which is hardwired. 
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transmitting and receiving stations to support the communication mission. Note that 
TECHCTL has no message entry or delivery capabilities. [Ref. 8: pp. 18-20] 

6. Receiver Site (RECSITE) 

The RECSITE serves as the primary and secondary ship/shore channel terminal 
area, using on-line channels from FLTCEN. Hardware is similar to that of the 
FLTCEN, but also includes 100 WPM TTY on-line channels. [Ref 8: pp. 11-18] 

7. Top Secret (TS) Control 

TS Control is the NAVCOMPARS area for receipt and delivery of Top 
Secret/Special Category (SPECAT) traffic. Using on-line and off-line processing, TS 
Control provides encryption, decryption, and delivery services. Note that TS Control 
may be a SVCEN function. [Ref 8: pp. 23-24] 

8. Operations Office (OPSOFF) 

The OPSOFF is the central management and control point for functions ex- 
ternal to the actual NAVCOMPARS; there are no hardware interfaces. Primary func- 
tions include report analysis (statistical/historical), traffic checks, and file maintenance. 
[Ref 8: pp.23-24] 

B. NAVCOMPARS SUBSYSTEMS 

When the NAVCOMPARS software was originally designed it was done with the 
concept of seperating system function into various subsystems. This concept of modu- 
larity meant that each subsystem was seperate with only uniform interface requirements 
for intrasubsystem communication. The NAVCOMPARS subsystems are: [Ref 8: p.65] 

1. AUTODIN Interface Subsystem (AIS) 

2. Executive Control Subsystem (ECS) 

3. AUTODIN Control Subsystem (ACS) 

4. Communication Control Subsystem (CCS) 

5. Receive Control Subsystem (RCS) 

6. Message Processing Subsystem (MPS) 

7. Transmission Processing Subsystem (TPS) 

8. Transmission Control Subsystem (TCS) 

9. Support Program Subsystem (SPS) 

10. System Service Subsystem 

See Figure 32 on page 70 for an illustration of NAVCOMPARS Subsystem organiza- 
tion [Ref 8: p.68]. 
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1. AUTODIN Interface Subsystem (AIS) 

The AIS serves as the interface between the NAVCOMPARS and the 
AUTODIN Switching Center (ASC). Primary duties are synchronization and error 
checking of incoming data from the ASC. [Ref. 8: p.65] 

2. Executive Control Subsystem (ECS) 

The ECS is the foundation for the NAVCOMPARS; ECS serves as the 
hardware software interface for the subsystems. ECS can be divided into four functional 
areas: console control, input/output (I/O) control, porgram control, and interrupt con- 
trol. [Ref. 8: pp. 65-66] 

3. AUTODIN Control Subsystem (ACS) 

The ACS serves as the interface for receipt and transmission of messages over 
AUTODIN. The interfacing is done between the RCS and TCS respectively. The type 
of interfacing by the ACS is channel initialization and message acknowledgement. [Ref. 
8: p.70] 

4. Communication Control Subsystem (CCS) 

The CCS, working with the ECS, provides both data flow control and 
logkeeping. The CCS controls flow by queueing communication device interrupts; ad- 
ditionally, the CCS provides recordkeeping for various input devices. [Ref. 8: p.70] 

5. Receive Control Subsystem (RCS) 

The RCS's primary’ duties include channel coordination, input buffering, and 
message format exchange. Channel coordination includes message sequence checking 
and error checking. The RCS also controls input buffers for incoming data; incoming 
data is later sent to seperate disk files for processing. The RCS additionally converts all 
incoming messages into a common code (EBCDIC) and format for processing. [Ref. 8: 
P-71] 

6. Message Processing Subsystem (MPS) 

The MPS performs the majority of message processing; processing includes 
message analysis, format conversion, routing indicator (RI) assignment, distribution as- 
signment, recalls and header processing. The MPS also acts as an interface for the sys- 
tem VDTs; types of actions include message recall requests, broadcast screens, and 
message editing and entry. [Ref 8: pp. 71-72] 
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7. Transmission Processing Subsystem (TPS) 

Altrouting, message journaling, channel scheduling, and transmission is per- 
formed by the TPS. The TPS also interfaces with the MPS to give queue status; the TPS 
also initiates and terminates message transmission with the TCS. [Ref. 8: pp.72-73] 

8. Transmission Control Subsystem (TCS) 

The TCS's purpose is to transmit messages to an output device, whether it is 
communication channel or terminal channel. The TCS also performs any format con- 
version necessary' to utilize the output device. The broadcast rerun function is also 
performed by the TCS. [Ref. 8: p.73J 

9. Support Program Subsytem (SPS) 

Report generation, file maintenance, and distribution assignment is performed 
by the SPS. Reports include historical data on message processing, routing files, and 
distribution files. [Ref. 8: pp.73-74] 

10. System Service Subsy stem 

The System Service Subsystem serves primarily as a utility program; it is re- 
sponsible for creating and maintaining the storage environment required by the 
NAVCOMPARS. [Ref. 8: p.74) 
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APPENDIX B. SIMULATION MODEL SPECIFICATIONS 

A. SIMULATION MODEL PROGRAM 
1. Model GPSS Code 

The following GPSS code is similar to the code used to run the simulations for 
this research. 



Test run - #AA/800/2S/30/100I 



REALLOCATE COM, 250000, XAC, 5000 
SIMULATE 

INITIAL XF1,0 

* 

* DEFINE FUNCTIONS 



MPREC 


FUNCTION 


RN1.D3 




. 33,1. 


0/. 66,2. 0/1. 


0,3. 0 




MLEN 


FUNCTION 


RN1.C2 




. 000,100/1. 0,2500 






MZYB 


FUNCTION 


RN1,D2 




. 30,0. 
* 


0/1. 0,1. 0 






* DEFINE VARIABLES 




PREC 


VARIABLE 


FN$MPREC 


PRECEDENCE CODE 


ADMIN 


VARIABLE 


FN$MZYB 


ADMIN/OPERATIONAL CODE 


MSGL 


VARIABLE 


FN$MLEN 


MESSAGE LENGTH (CHARACTER) 


TTIM 


VARIABLE 


(PF3*8)/75 


TRANSMISSION TIME (SECONDS) 


PPR 

•A* 


VARIABLE 


PF1-1 




* SIMULATION PROGRAM 

■A* 






GENERATE 


108,27, , , ,3PF 


TRANSACTION GENERATION 




ASSIGN 


1 , V$PREC , PF 


PRECEDENCE ASSIGNMENT 




ASSIGN 


2 ,V$ADMIN,PF 


ADMIN/OPERATIONAL CODE ASSIGNMENT 




ASSIGN 


3,V$MSGL,PF 


MSG LENGTH ASSIGNMENT 




PRIORITY 


V$PPR 


PRECEDENCE ASSIGNMENT 




TEST GE 


XF1 , 100 , RTN 


INTERCEPT TRIGGER 




TEST E 


PF2,1, ADMIN 


ADMIN MESSAGE CHECK 


RTN 


QUEUE 


QUE, 1 






PREEMPT 


OCHNL , PR 


FACILITY OCHNL SEIZED W/ PREEMPTION 




ADVANCE 


V$TTIM 


TRANSMISSION TIME 




RETURN 


OCHNL 






DEPART 


QUE, 1 






TABULATE 


TPREC 




TPREC 


TABLE 


PF1, 0,1,5 






TABULATE 


TADMN 
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TADMN 


TABLE 


PF2, 0,1,4 






SAVEVALUE 


1 ,QM1 ,XF 






TRANSFER 


,ENDD 




ADMIN 


TEST LE 


V$PPR,2,RTN 


ADMIN MESSAGE PRECEDENCE CHECK 




QUEUE 


RMAD.l 


QUEUE FOR INTERCEPTED MESSAGES 




DEPART 


RMAD, 1 






TRANSFER 


,ENDD 




ENDD 


TERMINATE 

GENERATE 


3600 


TRANSACTION TERMINATION 




TERMINATE 


1 






START 


24, ,2 





2. Model Functions 

1. MPREC - Message Precedence Assignment 

-code: 1.0 - Routine 

2.0 - Priority 

3.0 - Immediate 

-assignment by random number generation 

2. MLEN - Message Length Assignment (in characters) 

-continuous with low and high end ranges 
-assignment by random number generation 

3. MZYB - Message Type Assignment 

-code: 0.0 - administrative 

1.0 - operational 

-assignment by random number generation 

B. SIMULATION MODEL FLOW CHART 

In Figure 33 on page 75, the single output channel of the Fleet Broadcast is con- 
ceptualized as single server queue model into a general flow chart. Using this flow chart, 
the general flowchart is further decomposed into GPSS block diagrams in Figure 34 on 
page 76 and Figure 35 on page 77. 
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Figure 33. Simulation Model General Flow Chart 
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GENERATE 



ASSIGN PRECEDENCE 



ASSIGN MESSAGE TYPE 



ASSIGN MESSAGE LENGTH 



PRIORITY ASSIGNMENT 



TEST XF1 GE 100 
(QUEUE GE 100 MSGS) 



TEST PF2 E 1 
(IF OPERATIONAL) 



QUEUE OUE' 



PREEMPT 'OCHNL' 
(PRIORITY BASED) 



ADVANCE (TRANSMISSION TIME) 



Figure 34. Simulation Model Block. Diagram (a) 
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Figure 35. Simulation Model Block Diagram (l>) 
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APPENDIX C. DECISION MAKING AMONG MULTIPLE OBJECTIVES 



Many policy decisions today are very complex with extensive interaction among 
factors. To deal with these complex, unstructured situations has required the develop- 
ment of analytical processes to reach a decision taking into account all these interactive 
factors. Two such processes are: 

1. Multiattribute Utility Analysis 

2. The Analytical Hierarchy Process 

The following sections provide a brief description of each of the processes. For a de- 
tailed description the reader must refer to Ref. 26 and 27. 

A. MULTIATTRIBUTE UTILITY ANALYSIS 

Multiattribute Utility Analysis was developed as a means of allowing decision mak- 
ers to balance multiple objectives while at the same time incorporating personal judge- 
ments. By allowing personal judgements the process allows the inclusion of intangibles 
and preferences; this feature was lacking in earlier decision making processes. 

The analysis process is composed of the following four steps (Ref. 26: pp. 136- 139]: 

1. Defining attributes of value - These attributes are used to highlight the differences 
between the possible choices. 

2. Assessing performance of choices on each attributes - It is at this point where 
perference is assessed. Using a set scale of measure, for example, 0-100 for econ- 
omy, choices are ranked in each attribute. 

3. Determining tradeoffs across attributes - Using a set of weights, decision makers 
determine tradeoff across attributes. 

4. Calculating an overall average - Using a weighted average, a score is calculated for 
each choice. The resultant overall value is the choice's measure of attractiveness 
compared to the other choices. 

B. THE ANALYTICAL HIERARCHY PROCESS (AHP) 

AHP is based on three principles which are key to logical analysis: the principle of 
constructing hierarchies, the principle of establishing priorities, and the principle of log- 
ical consistency. AHP consists of the folio wing steps: 

1. Using a hierarchal concept, complex systems are broken down into constituent 
parts according to their essential relationships (Ref. 27: p.33]. 
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2. Step two requires the establishing of priorities. Using matrices, pairwise compar- 
ison is performed in an effort to find which elements dominate with respect to cri- 
terion on higher levels of the hierarchy. 

3. Step two is performed on all levels and clusters of the hierarchy. The end result is 
an overall priority vector for the lowest levels of the hierarchy [Ref. 27: p.94]. 



79 



APPENDIX D. GLOSSARY OF ACRONYMS 



ADM 


Message Redirect Command 


AHP 


Analytical Hierarchy Process 


ACS 


AUTODIN Control Subsystem 


AIS 


AUTODIN Interface Subsystem 


ALTROUTE 


Alternate Route 


AM 


Message Alternate Route Command 


AMSS 


Automatic Message Screening Subsystem 


ASC 


AUTODIN Switching Center 


AUTODIN 


Automatic Digital Information Network 


BKS 


Broadcast Keying Station 


BSR 


Broadcast Service Request 


CCS 


Communication Control Subsystem 


CNO 


Chief of Naval Operations 


CN'TC 


Commander, Naval Telecommunications 
Command 


COMMAREA 


Communications Area 


COMPCEN 


Computer Center 


CUDIXS 


Common User Digital Information Exchange 
System 


CVBG 


Carrier Battle Group 


DCS 


Defense Communications System 


EASTPAC 


Eastern Pacific 


ECS 


Executive Control Subsystem 


FIFO 


First in, First out 


FLTCEN 


Fleet Center 


FLTCINC 


Fleet Commander in Chief 


FLTSATCOM 


Fleet Satellite Communications System 


FOTP 


Fleet Operational Telecommunications Program 


FSB 


Fleet Satellite Broadcast 


GEXSER 


General Service 


GHZ 


Gigahertz 
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GPSS 


General Purpose Simulation System V 


HF 


High Frequency- 


HFB 


High Frequency Broadcast 


LAXT 


Atlantic 


LEASAT 


Leased Satellite System 


LRN 


Logical Reference Xumber 


LUF 


Lowest Useable Frequency 


MED 


Mediterranean 


MHI 


Message Handling Instruction 


MHZ 


Megahertz 


MPS 


Message Processing Subsystem 


MPSVC 


Message Processing Subsystem Software 
Module - Service Clerk Support 


MSGCEN 


Message Center 


MUF 


Maximum Useable Frequency 


MULCAST 


Multichannel Broadcast 


XAVCAMS 


Xaval Communications Area Master Station 


NAVCOMMSTA 


Xaval Communications Station 


NAVCOMPARS 


Xaval Communications Processing 
and Routing System 


XAVTELSYSIC 


Xaval Telecommunications Systems 
Integration Center 


XCQPROS 


Output Queue Profile Report 


XCQPROT 


Output Queue Profile Report 


XTS 


Xaval Telecommunications System 


OCR 


Optical Character Reader 


OPSIG 


Operating Signal 


OPSOFF 


Operations Office 


RCS 


Receive Control Subsystem 


RECSITE 


Receiver Site 


RI 


Routing Indicator 


SBO 


MPSVC SVC Reentry Command 


SBR 


MPSVC SVC Reentry Command 


SHF 


Super High Frequency 
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SPECAT 


Special Category 


SPS 


Support Program Subsystem 


SVC 


MPSVC Command 


SVCEN 


Service Center 


TECHCTL 


Technical Control 


TCS 


Transmission Control Subsystem 


TPS 


Transmission Processing Subsystem 


TS 


Top Secret 


TTY 


Teletype 


UHF 


Ultra High Frequency 


VDT 


Video Data Terminal 


WESTPAC 


Western Pacific 


WPM 


Words Per Minute 


ZYB 


Operating Signal for Administrative Message 
Designation 
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